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Sažetak. Rad predstavlja osnovne definicije unutar područja upravljanja projektima. Kroz povijesni se razvoj uočavaju glavne smjernice koje su 
vodile razvoj područja i postavile temelje defmicijama područja. Definicije pojmova iz područja upravljanja projektima (projekt, upravljanje 
projektom, program, portfelj) se razlikuju od autora do autora, iako se u svakoj definiciji mogu iščitati osnovne značajke, zajedničke svima 
autorima. Cijeli proces upravljanja projektom moguće je raščlaniti na osnovne dijelove i staviti ih u područja znanja upravljanja projektom. 
Zrelost procesa upravljanja projektom prikazana je kroz osnovne definicije i kroz nedavno istraživanje. Područje metodologija u upravljanju 
projektima određeno je osnovnim definicijama metodologija, pregledom tradicionalnoga pristupa upravljanju projektima te razvojem prema 
agilnim, odnosno adaptivnim i ostalim modemim metodologijama. Kao zaključak se nameće rnogući daljnji razvoj područja, vodeći računa o 

dosadašnjem razvoju i definicijama podmčja. 
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I. UVOD 

Ulazeći u 21. stoljeće, shvaćanje se područja upravljanja 
projektima promijenilo [17], Međutim, nije se samo pojavila 
potreba za implementacijom procesa fonnalnoga vođenja 
projekata, već se sve više uvode rješenja specifična za 
pojedino okruženje u kojem se projekt odvija. Takav 
dinamični razvoj područja slijedio je nakon nekoliko faza 
sazrijevanja. 

Područje upravljanja projektima, iako se razvilo iz 
tehničkih disciplina, s vremenom je pod utjecajem drugih 
područja sve više postalo multidisciplinamo. Tako za 
uspješan rad na cjelokupnom projektu treba uzeti u obzir, 
osim užega područja upravljanja projektima, prije svega 
organizacijsku strukturu i okruženje projekta i znanje s 
podmčja primjene projekta, standarde i pravni okvir, te 
općenito znanje iz poslovnoga upravljanja i međuljudskih 
odnosa. Svaki od tih čimbenika može imati veliki utjecaj na 
uspješnost projekta. 

II. Razvoj PodručJA 

Razvoj formalnoga upravljanja projektima započeo je 
1950-ih kao potreba Ministarstva obrane Sjedinjenih 
Američkih Država za razvojem složenih vojnih sustava. Time 
se potvrđuje i činjenica da je podmčje upravljanja projektima 
nastalo iz tradicionalnih inženjerskih disciplina [28]. 
Ispočetka je upravljanje projektima nametnuto iz potrebe za 
standardiziranjem procesa i uključivalo je jasne ciljeve pa su 
ekipe koje su dobile zadatak mogle pouzdano planirati. 

Najveći čimbenik daljnjega rasta podmčja bila je težina 
poslova unutar inženjerskih zanimanja [17]. U to je doba 
(1960-e) računalna industrija započela svoj jaki utjecaj na 
poslovna okruženja, te su se računala počela sve više rabiti za 
poslovne potrebe. U tim ranim početcima za sve se projekte 
rabio isti pristup, naslijeđen od ostalih inženjerskih disciplina. 
Međutim, brzorastuće podmčje računalne industrije često je 
imalo za posljedicu neuspješne projekte, bilo zbog 



neispunjenja rokova bilo zbog očekivanja kupaca. Postajalo je 
očitije da tradicionalni pristup nije prikladan za takve 
projekte. 

Paralelno s tradicionalnim pristupom počeli su se razvijati i 
novi pristupi, dok je ovaj tradicionalni i dalje ostao u 
primjeni. Nasuprot tradicionalnom inženjerskom pristupu, 
početno se razvio dinamični model [26], koji je morao 
odgovoriti na veće zahtjeve za kontrolom troškova nasuprot 
vrijednosti proizašloj iz projekata, a i sve većim zahtjevima za 
bržim postignućem ciljeva projekta. 

Kao krajnji korak u razvoju, dovodeći sva ograničenja 
vezana uz povećanje koristi proizašle iz projekta, brzom 
razvoju i velikim promjenama unutar projektnoga plana do 
velikoga izražaja, pojavio se ekstremni pristup [26]. 

III. DEFfNfCJJE PODRUČJA 

Za pokušaj definiranja pojma upravljanje projektom (eng. 
Project Management) potrebno je definirati pojam projekt. U 
Hrvatskoj je proces standardizacije podmčja još uvijek u 
začetku, pa tako i standardizacija nazivlja. U ovom je članku 
dan proizvoljan prijevod kako bi se, u najboljoj namjeri, 
podmčje opisalo na hrvatskom jeziku. 

Također, budući da je većina autora s područja upravljanja 
projektima sudjelovala na izradi kataloga znanja u izdanju 
PMI {Project Management Institute), PMBOK Guide, ili se u 
svojim radovima referenciraju na PMI, deflnicije PMI uzete 
su kao najopćenitije, dok su radovi ostalih autora navedeni 
ukoliko značajnije odstupaju od PMI definicije. PMI je 
međunarodna udruga za upravljanje projektima sa sjedištem u 
SAD-u i s ograncima po cijelom svijetu, pa tako i u 
Hrvatskoj. Zbog sjedišta u SAD-u, njezin je standard 
prihvaćen kao ANSI standard, koji primjenjuju i ogranci. 
Osim PMI, postoji još nekoliko udruga koje se bave 
promicanjem područja upravljanja projektima, od kojih su 
IPMA ( International Project Management Association) i 
APM ( Association of Project Management) najvažnije u 
Europi. Kao i PMI, i IPMA je izdala svoj skup znanja, IPMA 




Competence Baseline [16] kao i APM, Body of Knowledge 
[1], a nude i certificiranje voditelja projekata, kao i PMI. 

A. Projekt 

PMI definira projekt kao vremenski određeno nastojanje da 
se proizvede jedinstven proizvod, usluga ili rezultat [9][23]. 
Iz ove se definicije mogu iščitati dvije važne stvari koje 
razlikuju projekt od operativnoga posla. Prva je da je projekt 
privremena aktivnost, što označuje da projekt ima svoj 
početak i svoj kraj. Također, projektna ekipa okupljena je za 
vrijeme trajanja projekta, a nakon toga se raspušta. Drugim 
riječima, ljudski se resursi oslobađaju za druge projekte ili 
operativne poslove. Druga je karakteristika da je projektom 
stvoren jedinstveni proizvod. 

Kerzner definira projekt kao bilo koji niz aktivnosti i 
zadaća koji imaju određeni cilj, koji treba ispuniti određene 
specifikacije, imaju određen početak i kraj, ograničena 
financijska sredstva, troše resurse (i ljudske i tehničke) te su 
višefunkcionalne [17]. 

Kleim i Ludin definiraju pak projekt kao skup različitih 
aktivnosti obavljenih u logičkom nizu kako bi se došlo do 
određenoga rezultata. Dodaju da svaka aktivnost kao i cijeli 
projekt imaju definiran početak i kraj [18]. 

Uglavnom, svi su autori prilikom defmicije projekta složni 
u tome da projekt ima vijek trajanja te da je u postizanju 
određenoga, jedinstvenog cilja potrebno poduzeti neke 
aktivnosti [1 1][13][28]. Stoga se kao osnovna definicija može 
uzeti definicija PMI, pogotovo jer djeluje i u Hrvatskoj, pa je 
i za očekivati formalnu definiciju. 




Dostupnost resursa 



Slika 1 . Osnovne varijable unutar projekta („trokut dosega“) [28] 

B. Upravljanje projektom 

Ako se uzme u obzir PMI definicija projekta kao 
najopćenitija, upravljanje projektom jest primjena znanja, 
vještina, alata i tehnika u projektnim aktivnostima da bi se 
ispunili projektni zahtjevi [9][23]. Upravljanje projektom 
uključuje utvrđivanje zahtjeva, postavljanje jasnih i ostvarivih 
ciljeva, uspostavu ravnoteže između suprotstavljenih zahtjeva 
za kvalitetu, doseg, vrijeme i trošak te prilagodbu 
specifikacija, planova i pristupa interesima i očekivanjima 
različitim zainteresiranim stranama. 

Iako većina autora vrlo slično definira područje 
upravljanjima projektom [13][16][17][18], zanimljivo je 
stajalište da je upravljanje projektom i umjetnost i znanost 
[11]. Umjetnost, jer je potrebno voditi ljude na projektu 



kojega je cilj da ljudi nešto naprave, a znanost zbog 
definiranja i koordinacije potrebnoga posla. 

Također, vrlo je općenita definicija da je upravljanje 
projektom metoda i skup tehnika temeljenih na prihvaćenim 
principima upravljanja rabljenim za planiranje, procjenu i 
kontrolu radnih aktivnosti u svrhu postizanja željenoga cilja 
na vrijeme i unutar proračuna te prema specifikacijama [28], 

C. Program i portfelj 

Cijeli proces upravljanja projektima odvija se u širem 
kontekstu od jednoga projekta, naročito u većim 
organizacijama. Zbog toga su se pojavili pojmovi programa i 
portfelja (eng. portfolio) te sukladno tomu pojmovi 
upravljanja programima i upravljanje portfeljem. Pod 
pojmom program označuje se skupina međusobno povezanih 
projekata organiziranih da priskrbe korist koja ne bi bila 
moguća da je riječ o samostalnim projektima [9][23]. Portfelj 
je skup projekata ili programa i ostaloga posla koji su 
grupirani zajedno kako bi se moglo djelotvomo upravljati tim 
poslom u svrhu postizanja strateških poslovnih ciljeva [23], 

Upravo radi postizanja strateških ciljeva kompanije 
(organizacije) i boljeg upravljanja projektima, programima i 
resursima, često se u nekom organizacijskom obliku formira 
središnji nadzor nad projektima. 

D. Proces upravljanja projektom (procesi projekta) 

Proces je skup međuzavisnih akcija i aktivnosti koje se 
izvode kako bi se postignuo predodređeni skup proizvoda, 
rezultata ili usluga [23]. Postoje dvije glavne kategorije 
projektnih procesa, procesi upravljanja projektom i procesi 
okrenuti proizvodu koji se međusobno preklapaju i 
međudjeluju u tijeku trajanja projekta. 




Slika 2. Grupe procesa u tijeku trajanja projekta [9] [23] 



Procesi projekta predstavljeni su kao jedinstveni elementi s 
dobro definiranim sučeljem, iako se u praksi preklapaju na 
načine koje je teško defmirati. Procese je moguće podijeliti u 
nekoliko skupina [9][23] : 

• grupa procesa započimanja (eng. Initiating Process 
Group) - defmira i odobrava projekt ili fazu projekta; 

• grupa procesa planiranja (eng. Planning Process 
Group) - definira i istančava svrhu, planira smjer i 
akcije za postizanje cilja i dosega; 



• grupa upravljačkih procesa (eng. Executing Process 
Group) - koordinira ljudske i druge resurse u svrhu 
provedbe plana; 

• grupa procesa (eng. Monitoring and Controlling 
Process Group ) - mjeri i prati napredak radi uočavanja 
odstupanja od plana i poduzimanja korektivnih akcija; 

• grupa završnih procesa (eng. Closing Process Group ) 
- formalizira prihvaćanje proizvoda, usluge ili 
rezultata te dovodi do završetka projekta ili faze 
projekta. 

Za uspješno vođenje projekta potrebno je odabrati 
prikladan skup procesa ne temelju složenosti, rizika, veličine, 
vremenskoga okvira, iskustva projektne ekipe, dostupnosti 
resursa, količine dostupnih infonnacija, organizacijske 
zrelosti na području upravljanja projektima te na području 
primjene. To su ujedno i varijable prema kojima se projekti 
mogu razvrstati u skupine. 

E. Područja upravljanja projektom 

Svi procesi, njih ukupno 44, unutar navedenih grupa 
pripadaju određenim područjima upravljanja projektom, 
odnosno područjima znanja (eng. Knowledge Areas) [9][23]: 

• Koordinacija projekta (eng. Project Integration 
Management) 

o Razvoj idejnoga rješenja (eng. Develop Project 
Charter) 

o Razvoj početne izjave o dosegu projekta (eng. 

Develop Preliminarv Project Scope Statement) 
o Razvoj plana upravljanja projektom (eng. Develop 
Project Management Plan) 

o Usmjeravanje i upravljanje izvršenja projekta (eng. 

Direct and Manage Project Execution) 
o Praćenje i nadzor rada na projektu (eng. Monitor 
and Control Project Work) 

o Koordinirani nadzor nad promjenama (eng. 

Integrated Change Control) 
o Zatvaranje projekta (eng. Close Project) 

• Upravljanje dosegom projekta (eng. Project Scope 
Management) 

o Planiranje dosega (eng. Scope Planning) 
o Definiranje dosega (eng. Scope Defmition) 
o Strukturiranje raspodjele posla (eng. Create Work 
Breakdown Structure) 

o Verifikacija dosega (eng. Scope Verificatiori) 
o Nadzor nad dosegom (eng. Scope Control ) 

• Upravljanje vremenskim rasporedom projekta (eng. 
Project Time Management) 

o Definiranje aktivnosti (eng. Activitv Definition) 
o Određivanje poretka aktivnosti (eng. Activitv 
Sequencing) 

o Procjena resursa aktivnosti (eng. Activitv Resource 
Estimating) 

o Procjena trajanja aktivnosti (eng. Activitv Duration 
Estimating) 

o Izrada vremenskoga rasporeda (eng. Schedule 
Development) 

o Nadzor ispunjenja rokova (eng. Schedule Control) 



• Upravljanje troškovima projekta (eng. Project Cost 
Management) 

o Procjena troškova (eng. Cost Estimating) 
o Upravljanje proračunom (eng. Cost Budgeting) 
o Nadzor nad troškovima (eng. Cost Control) 

• Upravljanje kvalitetom projekta (eng. Project Qualitv 
Management) 

o Planiranje kvalitete (eng. Quality Planning) 
o Osiguravanje kvalitete (eng. Perform Qualitv 
Assurance) 

o Nadzor nad kvalitetom (eng. Perform Quality 

Control) 

• Upravljanje ljudskim resursima projekta (eng. Project 
Human Resource Management) 

o Planiranje ljudskih resursa (eng. Human Resource 
Planning) 

o Prikupljanje projektne ekipe (eng. Acquire Project 
Team) 

o Razvoj projektne ekipe (eng. Develop Project 

Team) 

o Rukovođenje projektnom ekipom (eng. Manage 
Project Team) 

• Upravljanje razmjenom informacija u projektu (eng. 
Project Communications Management) 

o Planiranje komunikacije (eng. Communications 

Planning) 

o Distribuiranje informacija (eng. Information 

Distribution) 

o Izvješćivanje o provedbi (eng. Performance 

Reporting) 

o Koordiniranje zainteresiranih strana (eng. Manage 
Stakeholders) 

• Upravljanje rizicima projekta (eng. Project Risk 
Management) 

o Planiranje upravljanja rizicima (eng. Risk 

Management Planning) 

o Prepoznavanje rizika (eng. Risk Identification) 
o Kvalitativna analiza rizika (eng. Qualitative Risk 
Analvsis) 

o Kvantitativna analiza rizika (eng. Quantitative Risk 
Analvsis) 

o Plan ublažavanja rizika (eng. Risk Response 

Planning) 

o Praćenje i nadzor rizika (eng. Risk Monitoring and 
Control) 

• Upravljanje nabavom za potrebe projekta (eng. Project 
Procurement Management) 

o Planiranje kupovine i nabavke (eng. Plan Purchase 
and Acquisitions) 

o Planiranje ugovaranja (eng. Plan Contracting) 
o Prikupljanje ponuda (eng. Request Seller 

Responses) 

o Odabir dobavljača (eng. Select Sellers) 
o Administriranje ugovora (eng. Contract 
Administration) 

o Zatvaranje ugovora (eng. Contract Closure) 




F. Model zrelosti 

Model zrelosti (eng. Maturitv ModeJ) procesa prvi je 
ponudio Humphrey [14] u području softverskog inženjerstva. 
Нирћгеу je definirao softverski proces kao skup alata, metoda 
i prakse koje rabimo kako bi proizveli softverski proizvod. 
Također, svaki se zadatak može promatrati kao proces koji se 
može kontrolirati, izmjeriti te poboljšati. Zrelost procesa 
unutar organizacije se sastoji od pet razina: 

1. Inicijalna (eng. Initial ) - sve dok proces nije unutar 
statističke kontrole, daljnji napredak nije moguć, a prvi 
je korak postizanje osnovne procjene vremena i 
troškova; 

2. Ponavljajuća (eng. Repeatable) - stabilan proces s 
ponavljajućim stupnjem statističke kontrole te 
pokretanjem čvrstoga nadzora nad obvezama, 
troškovima, vremenom i promjenama; 

3. Definirana (eng. Defined) - definirani proces služi kao 
temelj za dosljednu primjenu i bolje razumijevanje te 
se može rabiti napredna tehnologija; 

4. Upravljana (eng. Managed) - pokrenuto je temeljno 
mjerenje i analiza procesa i tu počinje najvažnije 
poboljšanje kvalitete; 

5. Optimizirana (eng. Optimized) - postoji temelj za 
kontinuirano poboljšanje i optimizaciju procesa. 

Glavni cilj ovakve raspodjele razina zrelosti jest postizanje 
kontroliranoga i mjerljivoga procesa kao osnove za daljnja 
poboljšanja, te je namijenjena za ispitivanje metodologije i 
upravljačkoga sustava. 
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Slika 3. SEI Model zrelosti [14] 

Nastavno na predloženi model, SEI (Software Engineering 
Institute), kojega je i Humphrey bio član, razvio je integraciju 
modela sposobnosti i zrelosti - CMMI (eng. Capabilitv 
Maturitv Model Integration) [3]. CMMI je razvijen za 
nekoliko područja, pa tako i za područje upravljanja 
projektima, te razlikuje stupnjeve sposobnosti organizacije za 
pojedine dijelove procesa (nepotpuni, obavljajući, upravljani, 
definirani, kvantitativno upravljani, optimizirani) od 
stupnjeva zrelosti cjelokupne organizacije (inicijalni, 
upravljani, definirani, kvantitativno upravljani, optimizirani). 



Iako se neki autori pozivaju ne nedostatke modela [25], čak se 
i oni u svojim radovima referenciraju na predloženi model. 

Kerzner [17] također definira model zrelosti upravljanja 
projektom PMMM (Project Management Maturitv Model) u 
pet razina: zajednički jezik, zajednički procesi, jedinstvena 
metodologija, mjerenje, neprekidno poboljšanje. Isto tako, 
definira zrelost na području upravljanja projektom kao 
implementaciju standardne metodologije i pratećih procesa u 
toj mjeri da postoji velika vjerojatnost u ponovljenu 
uspješnost. Zrelost se razlikuje od izvrsnosti, jer izvrsnost ide 
dalje od zrelosti budući da stvara okruženje u kojem postoji 
neprekidni niz uspješnih projekata i u kojem se uspješnost 
mjeri u interesu i organizacije i projekta. 

Također, PMI definira model organizacijske zrelosti 
upravljanja projektima [24] s trima najvažnijim dijelovima: 
znanjem, ispitivanjem i poboljšanjem, te navodi i niz pravila 
kako primijeniti model u organizaciji. 

SEI CMMI kao temelj uzima i britanski OGC, postavljajući 
svoj model zrelosti upravljanja portfeljem, programom i 
projektom (eng. Portfolio, Programme & Project 
Management Maturitv Model - РЗМЗ) [21]. 

Nedavno istraživanje [10] kombiniralo je SEI model 
zrelosti i PMI područja znanja, te je zaključeno da je velika 
većina organizacija općenito gledano u drugoj razini (53,2%), 
malo manje u prvoj i trećoj, dok je skoro zanemariva količina 
organizacija u četvrtoj i petoj razini. Iako je nezahvalno i 
prilično teško svaku razinu promatrati kao zasebnu cjelinu, 
moguće je izračunati da je srednja vrijednost i procesa u 
organizaciji i samih organizacija druga razina. 

IV. Metodologije 

A. Defmicija metode i metodologije 

Metodologija je, prema PMI definiciji, sustav praksi, 
tehnika, procedura i pravila koje rabi onaj tko radi na 
području određene discipline [23], gdje je procedura niz 
koraka koji se da bi se nešto postignulo, odvijaju po 
redoslijedu. 

Charvat [2] pak definira metodologiju kao skup smjemica i 
principa koji se mogu skrojiti i primijeniti specifičnoj 
situaciji. U projektnom okruženju te smjemice mogu biti 
popis stvari koje treba napraviti. Također, metodologija može 
biti specifičan pristup, predlošci, obrasci rabljeni kroz životni 
ciklus projekta. 

Iako postoje i dmgačije definicije, može se reći da 
metodologija nikako nije privremeno rješenje, kuharica za 
uspješan projekt, srebmi metak ili brzi popravak. 

Dobra metodologija sadržava sve važne procese 
upravljanja projektom, te će se podmčja koja su uključena u 
procese i dalje širiti [17]. Također, Kerzner navodi da su 
karakteristike dobre metodologije prepomčen stupanj detalja, 
uporaba predložaka, standardizirane tehnike planiranja, 
vremenskoga određivanja i kontrole troškova, standardizirani 
oblik izvještavanja, fleksibilnost za primjenu na svim 
projektima, fleksibilnost za brzi razvoj, razumljivost 
korisniku, prihvaćenost i uporabljivost u organizaciji, uporaba 
standardiziranih faza životnoga ciklusa te temeljenost na 





smjemicama (umjesto na procedurama) i na etici dobro 
obavljenoga posla. Ukoliko se sve dobro primijeni, zbog bolje 
kontrole nad dosegom projekta može se očekivati brže 
vrijeme izlaska na tržište smanjeni rizik projekta, bolji proces 
donošenja odluka, veće zadovoljstvo kupca te više vremena 
za dodane vrijednosti. 

Slično prethodnim deflnicijama, metodologijom se mogu 
smatrati uloge, ekipe, vještine, procesi, tehnike, alati i 
standardi koje rabi projektna ekipa [5], Također, može se reći 
da ukoliko to primjenjuje jedna ili dvije osobe, onda se može 
nazvati metodom, a ukoliko to primjenjuje cijela ekipa, može 
se nazvati metodologijom. 

B. Tradicionalni pristup 

Tradicionalni pristup upravljanju projektom temelji se na 
upravljanju ljudima, dakle isto kao i upravljanje općenito 
gledano [28], Temeljni principi uključuju niz tehnika za 
planiranje, predviđanje i kontrolu aktivnosti radi postizanja 
željenoga rezultata prema zadanim specifikacijama u 
određenom vremenu i s određenim troškovima [5][ 1 7]. 

Tradicionalni pristup uzet je i kao temelj podjele grupa 
procesa prema PMI [23], 

Kao prvi zadatak koji se stavlja ispred voditelja projekta i 
projektne ekipe jest definiranje zadataka i izvršitelja. U nekim 
slučajevima, definiranje zadataka potrebno je napraviti čak i 
prije formalnoga početka projekta. Za dobro i uspješno 
planiranje potrebno je odgovoriti na pet temeljnih pitanja: o 
kojem se problemu radu, koji je cilj projekta, koji se zadatci 
moraju obaviti kako bi se došlo do cilja, kako će se odrediti 
uspješnost projekta te postoje li neke pretpostavke, rizici ili 
prepreke koje mogu utjecati na uspješnost projekta. Procesom 
planiranja određuje se doseg projekta. 

Iako se planiranje često drži nepotrebnim poslom, ono je 
drugi korak u provođenju projekta. U tradicionalnom pristupu 
plan je temelj svega jer predstavlja ne samo opis poslova i 
vremena potrebnoga za njihovo provođenje nego i alat za 
donošenje odluka. Pri planiranju se određuju zadatci i 
dodjeljuju određenim članovima ekipe prema potrebnim 
vještinama za ispunjenje zadatka. Planiranje smanjuje 
nesigumost, jer pruža mogućnost ispravljanja krivih koraka u 
postizanju željenoga cilja, povećava razumijevanje ciljeva i 
zadataka projekta te povećava djelotvomost uzimanjem u 
obzir moguće raspodjele posla u odnosu na vremenski plan i 
dostupnost resursa. 

Izvršenje kao idući korak u principu je dozvola za 
obavljanje dodijeljenih zadataka. Izvršenje se odvija u četiri 
koraka: određivanje specifičnih resursa potrebnih za 

obavljanje dodijeljenoga zadatka prema planu, raspodjela 
članova prema planiranim aktivnostima, određivanje 
vremenskoga trajanja aktivnosti s točno utvrđenim početkom 
i krajem te samo pokretanje planirane aktivnosti, odnosno 
izvršenje u užem smislu. 

Tijekom izvršenja potrebno je kontrolirati da odvija li se 
sve prema planiranim aktivnostima, pošto je cijelo vrijeme 
potrebno motriti razvoj projekta kako bi se ispravile uočene 
nepravilnosti i kako bi se završilo projekt na vrijeme i uz 



planirane troškove. Naravno, osim vremena i troškova, 
preduvjet je uspješno obavljen zadatak. 

Na kraju je projekt potrebno i formalno završiti, odnosno 
zatvoriti. Time se pokazuje završetak zadataka i predaja 
obavljenoga posla te se oslobađaju resursi koji se sada mogu 
pridijeliti nekom novom projektu. Također, tijekom 
zatvaranja projekta obavlja se evaluacija, koja u određenim 
situacijama i organizacijama može poslužiti kao vrijedan 
izvor znanja, pogotovo ako se dogodilo nešto nepredviđeno, a 
uspješno je svladano. Ukoliko je zatvaranje projekta 
kvalitetno napravljeno, moguće je odgovoriti na pitanja 
odgovara li isporučeno rješenje očekivanjima onoga tko je 
zatražio takvo rješenje i voditelja projekta, je li projektna 
ekipa završila projekt prema predviđenom planu, koje su 
informacije prikupljene kao vrijedna pomoć za buduće 
projekte, kako se odabrana metodologija rabila tijekom 
projekta, je li utjecala na uspješnost njegova završetka te koji 
se poučci mogu izvući iz projekta. Sve te karakteristike 
ukazuju da je završetak projekta vrlo važan dio, ali je unatoč 
tomu često zanemaren najčešće zbog pritiska da se odmah 
počne rad na idućem projektu. 

Svi se ti koraci u fonnalnijoj podijeli nazivaju fazama 
životnoga ciklusa projekta [ 1 7] [28]. Također, moguće je 
iskoristiti i samo one faze koje su potrebne za određeni 
projekt, ali su u tom slučaju prve tri faze (definiranje, 
planiranje, organiziranje - izvršenje) uvijek obvezne dok se 
faze kontrole i završetka mogu dodati u zavisnosti od veličine 
i vrste projekta. 




I Zatvaranje 



Slika 4. Koraci u tradicionalnom upravljanju projektom [5] 

Veliki naglasak u tradicionalnom pristupu iskazan je za 
područje upravljanja kvalitetom, kako proizvoda, usluge ili 
procesa kao završnoga izlaza iz projekta, tako i samoga 
procesa upravljanja projektom. 

U zadnje je vrijeme veća količina radova posvećena 
upravljanju rizicima unutar projekta, jer je primijećeno da se 
u prošlosti veći naglasak stavljao na vrijeme i trošak, što je 
vidljivo i iz brojnosti članaka o tim temama [22]. 

Općenito, tradicionalni je pristup vrlo robustan i 
omogućuje primjenu od najjednostavnijih do 




najkompliciranijih projekata, jer se tijekom projekta uvijek 
primjenjuju identični koraci. 

C. Agilne metodologije 

Kao rezultat sve većega zahtjeva za neprekidnim 
inovacijama koje su zahvatile sve industrijske grane i borbe 
za smanjenjem troškova, grupa autora osmislila je novi 
pristup procesu razvoja. Kao i svaki istraživački proces, 
temelji se na nekoliko poslovnih principa: neprekidna 
inovacija, prilagodba proizvoda, smanjenje vremena isporuke, 
prilagodba ljudi i procesa te pouzdani rezultati [12]. Sve je to 
uključeno u pojam agilnost, koji odražava više stav nego 
proces. Prema Highsmithu je agilnost sposobnost i da se 
stvori i da se odgovori na promjenu kako bi se ostvarila dobit 
u turbulentnom poslovnom okruženju. Također, agilnost je 
sposobnost da se balansira između fleksibilnosti i stabilnosti. 

Skupina autora izdala je 2001. Manifest za agilni razvoj 
softvera [19] u kojem su postavili četiri temeljne vrijednosti 
agilnoga upravljanja projektima: osobe i odnosi ispred 
procesa i alata, radeći proizvod ispred opsežne 
dokumentacije, suradnja s kupcem ispred pregovaranja 
ugovora, odgovaranje na promjenu ispred slijeđenja plana. 
Međutim, time se ne ističe da su procesi, alati, dokumentacija, 
ugovori i plan nevažni nego da su manje važni. 

Iako je Manifest napisan u prvom redu za agilni razvoj 
softvera, temeljne vrijednosti mogu se primijeniti izravno, uz 
neznatne promjene, i na agilno upravljanje projektom. Agilne 
metodologije su prema tome namijenjene razvoju softvera, ali 
se može povući paralela sa upravljanjem projektom i reći da 
za je upravljanje kreativnim ljudima i procesima potreban i 
kreativan upravljački proces [26], 

a. Model agilnoga upravljanja projektom 

Predstavljeni model [12] temelji se na tradicionalnom 
modelu i njegovih pet faza, ali su te faze zamijenjene 
prikladnijima: 

• Isplanirati viziju (eng. Envision) - odrediti viziju i 
doseg projekta te projektnu organizaciju (umjesto 
inicijalne faze, da se naglasi važnost vizije); 

• Nagađati (eng. Speculate) - razviti model određen 
značajkama, vremenske odrednice te plan iteracija za 
ostvarenje vizije (umjesto planiranja, da se naglasi 
nesigurnost jer je plan povezan sa određenošću); 

• Istraživati (eng. Explore) - isporučiti testirane dijelove 
u kratkom razdoblju te stalno tražiti način za 
smanjenje rizika i nesigumosti unutar projekt (umjesto 
upravljanja, jer je istraživanje naglašeno iterativno, 
odnosno nelineamo); 

• Prilagoditi (eng. Adapt) - pregledati ispomčene 
rezultate, trenutnu situaciju i ponašanje ekipe te 
prilagoditi ukoliko je potrebno; 

• Zatvoriti (eng. Close) - završiti projekt, prenijeti 
ključne stvari koje su se naučile u tijeku projekta te 
proslaviti. 

Agilne metodologije naglašavaju iterativni pristup projektu 
te su prikladne za projekte različitih veličina iako će 
vjerojatno postojati potreba za dodatnim procesima ukoliko se 



radi o izrazito velikoj projektnoj ekipi pa se stvara dojam da 
je ipak agilne metodologije primijeniti u manjim ekipama. 

b. Ekstremno upravljanje projektima 

Ekstremno upravljanje projektima (eng. Extreme Project 
Management) nastalo je na temeljima ekstremnog 
programiranja (eng. Extreme Programming - ХР). ХР ima 
samo jedan cilj, završiti projekt na kojem se radi, 
primjenjujući niz jednostavnih principa. Životni ciklus se 
sastoji od 5 faza, kojima je malo promijenjen naziv: 
istraživanje, planiranje, iteracije do završnog među- 
proizvoda, pretvaranje u proizvod, održavanje i smrt [7]. 

c. SCRUM 

SCRUM kao razvojna metodologija uključuje nekoliko 
varijabli okoline i tehničkih varijabli koje imaju veliku 
vjerojatnost promjene u tijeku procesa. Koncentrira se na 
organizaciju ekipe, što je i logično s obzirom da je nastao 
prema ragbiju. Životni ciklus se sastoji od 3 faze: prije igre, 
razvoj, poslije igre. 

d. Metoda dinamičkog razvoja sustava 

Metoda dinamičkog razvoja sustava (eng. Dvnamic Svstem 
Development Method - DSDM) na početku postavlja vrijeme 
i dostupne resurse te prema tome prilagođava količinu 
funkcionalnosti. Životni ciklus se sastoji od pet faza: studija 
izvodivosti, studija isplativosti, iteracija funkcijskog modela, 
iteracija dizajna i izgradnje te implementacija. 

e. Crvstal 

Crystal je metodologija koju je na temelju svog rada i 
proučavanja osmislio Cockburn [4], Glavna okosnica je 
činjenica da je metodologiju moguće odabrati na osnovu tri 
čimbenika: količine komunikacije koju određuje veličina 
ekipe, stupnju kritičnosti sustava te prioritetima projekta. 
Pošto je Crystal nastao prije ХР, moguće je reći da Crystal 
pokazuje ono što ХР naglašava, odnosno da se rad može 
smanjiti i time ubrzati isporuka projekta zbog poboljšane 
komunikacije unutar projektne ekipe. 

f. Utjecaj agilnih metoda razvoja na upravljanje projektom 

Osim nabrojanih, postoji još nekoliko metodologija koje 

pripadaju agilnoj obitelji metodologija poput adaptivnog 
razvoja sustava (eng. Adaptive Svstems Development), razvoj 
vođen osobinama (eng. Feature Driven Design), objektno 
orijentirani razvoj te druge. Sve one utječu na pripadajući 
oblik upravljanja projektom, međutim glavne se značajke 
uklapaju u definiciju obitelji agilnih metodologija. 

Ukoliko su za određeni projekt poznati zahtjevi, dostupni 
resursi, te vanjski čimbenici poput poslovnih i pravnih 
ograničenja, agilne metodologije se mogu primijeniti na 
projekt. Pri tome se mora voditi računa da agilne 
metodologije utječu i na ljude (razvojno osoblje, voditelji 
projekata, kupci, upravljačke strukture, projektna ekipa) i na 
procese (planiranje, dokumentacija, razvojni procesi) i na sam 
projekt (vrsta projekta, poslovni čimbenici, ostale 
karakteristike). Svi ti čimbenici moraju se uzeti u obzir 




prilikom određivanja koja je agilna metodologija 
najprikladnija, te da li je uopće agilni pristup prikladan. 
Naravno, svaka metodologija sadrži specifičan skup tehnika 
koje je moguće primijeniti. 

Najprikladnija primjena je u projektima s velikom 
nesigumošću i visokom razinom promjena, iako se i u ostalim 
projektima mogu primijeniti, ali uz nadopune sa 
tradicionalnim dijelovima. 

D. Adaptivno projektno okruženje 

Vrlo je brzo nakon početnoga oduševljenja agilnim 
metodologijama postalo očigledno da agilni pristup ne 
odgovara svim vrstama projekata, kao i tradicionalni pristup. 
U pokušaju ispunjenja praznine između dviju krajnosti, 
nastalo je adaptivno projektno okruženje (eng. Adaptive 
Project Framevvork) [28]. 

Adaptivno projektno okruženje temelji se na planu kojega 
se slijedi u potpunosti, ali za razliku od tradicionalnog 
pristupa, plan nije izrađen na početku već ciklički u tijeku 
projekta, dok su vrijeme i troškovi zadani na početku 
projekta. 

Dakle, adaptivno projektno okruženje je ciklički i adaptivni 
pristup koji se sastoji od pet faza, te je namijenjen 
omogućavanju maksimalne poslovne koristi klijentima unutar 
granica vremena i troškova. Faze adaptivnoga projektnoga 
okruženja su: doseg verzije, plan ciklusa, izgradnja ciklusa, 
provjera klijenta i osvrt na verziju. Temeljna misao vodilja 
kroz cijeli proces je ta da se u plan uvrste samo one aktivnosti 
za koje je sigumo da će biti dio konačnog rješenja. Na taj se 
način u idućim iteracijama dolazi do detaljnijeg rješenja. 
Ukoliko je potrebno, prvi ciklus, odnosno iteracija, u procesu 
može biti konceptualni dio kao uvod u ostale iteracije razvoja 
projekta. 

Međutim, kao i većina metodologija, i adaptivno projektno 
okruženje predstavlja način mišljenja, usmjeren prema 
klijentu. Takav način razmišljanja očituje se u temeljnim 
vrijednostima koje se moraju poštivati u svakom projektu 
vođenom ovom metodologijom. Temeljne vrijednosti su: 
usredotočenost na klijenta, upravljanje procesom povjereno 
klijentu, inkrementalni rezultati vrlo brzo i vrlo često, 
neprekidno propitivanje, ideja da je promjena napredak prema 
boljem rješenju te da nije potrebno nagađati o budućnosti. 

Ovakvim skupom temeljnih vrijednosti cijeli proces je 
stavljen u okvir u kojem se odvija, sa značajnim udjelom 
klijenta u samom procesu i sa neprekidnim poboljšanjima 
postojećeg rješenja. 

E. Ostala projektna okruženja 

Osim navedenih projektnih okruženja, razvijeno je još 
nekoliko fonnalizama, uglavnom temeljenih na 
tradicionalnom pristupu. Razlike su primjetne s obzirom na 
rizik unutar projekta, jednostavnost implementacije i 
upravljanja, veličinu projektne ekipe i podršku učestalim 
promjenama. Svi su pristupi, što je i karakteristika 
tradicionalnog pristupa, pouzdani, orijentirani dokumentaciji 
te pružaju podršku promjenama dosega i implementiraju fazni 
pristup projektu. 



Jedna od poznatijih metodologija je PRINCE2 (akronim, 
eng. Projects in Controlled Environments) koja je postala 
standard za IT projekte u Velikoj Britaniji te je u vladinoj 
nadležnosti [20]. Glavne osobine su definirana struktura 
upravljanja projektom, fleksibilne točke odluke, sustav 
planiranja resursa, skup kontroliranih procedura, fokusiranost 
na proizvode kroz cijeli projekt [2], Naravno, metodologija se 
može primijeniti i na ostale projekte izvan područja 
infonnacijskih tehnologija. 

RUP (eng. Rational Unified Process) je prilagodljiva 
projektna okolina namijenjena prvenstveno razvoju softvera 
[RUP]. Iako elektronička inačica dolazi s nekoliko 
predefiniranih procesa, moguće je prilagoditi proces prema 
potrebama projekta. RUP sadrži osnovne karakteristike 
modemog razvoja softvera poput iterativnog razvoja, 
arhitekture temeljene na komponentama, vizualnom 
modeliranju, upravljanju zahtjevima, stalne kontrole kvalitete 
te kontrolirane promjene [2], 

Ostale metodologije uključuju metodologiju razvojnoga 
životnoga ciklusa sustava (eng. Svstem Development Life 
Cvcle Methodologv, SDLC), metodologiju temeljenu na 
rješenju (eng. Solutions-Based Project Methodologv), 
objektno orijentiranu metodologiju (eng. Object Oriented 
Methodologv), koja je više usmjerena razvoju, evolucionamo 
upravljanje projektom (Evo), te razne hibridne metodologije 
[ 2 ], 

V. Zaključak 

Svaki projekt je jedinstven. Ovakva tvrdnja je izravna 
posljedica defmicije projekta. Nasuprot tome, i svaki je 
pojedinac, pa tako i onaj u projektnoj ekipi, jedinstven, kao i 
svaka organizacija sa svojim pravilima i svojim okmženjem, 
svojom kulturom. 

Metodologije upravljanja projektom nastale su na podlozi 
te različitosti, kada je postalo očito da jedinstven pristup 
problemu upravljanja projektom ne zadovoljava jedinstvene 
zahtjeve projekta. U takvom je okmženju nastalo više 
metodologija koje svaka na svoj način pokušavaju stvoriti 
okmženje koje je primjenjivo na sve projekte unutar podmčja 
ili čak na projekte iz svih podmčja. 

Međutim, postaje sve očitije da jedinstveni projekt 
zahtijeva i jedinstveni pristup upravljanju projektom, 
svojstvenim samo za taj projekt. Sve je više kritičara 
tradicionalnog pristupa, kojem zamjeraju nedovoljnu 
fleksibilnost i višak posla za jednostavnije projekte. Agilne 
metodologije predstavljaju krajnost u kojoj je sav nepotreban 
posao zanemaren. Kritičari im pak zamjeraju nedostatak 
dokaza o uspješnosti projekata vođenih tim metodologijama. 

Vodeći računa da će u budućnosti projekti postajati još 
kompliciraniji i da će se od metodologija upravljanja 
projektom zahtijevati primjena na takvom projektu, vrlo je 
važan pravilan odabir metodologije unutar organizacije. 
Metodologija se mora odabrati vodeći računa o primjenjivosti 
na sve projekte unutar organizacije. Međutim, vrlo je 
vjerojatno da niti jedna od postojećih metodologija neće 
zadovoljiti baš sve projekte. 




Jedno od mogućih rješenja je stvaranje generičke 
metodologije, temeljene na postojećim metodologijama, koju 
je moguće oblikovati prema projektu, čak i prilagoditi u tijeku 
projekta. Vrlo važan korak u tom oblikovanju predstavlja 
učenje na temelju iskustva završenih projekata. Na taj način je 
moguće proširiti sustav sa novim znanjem, bilo da je riječ o 
znanju iz završenog projekta, bilo da je riječ o novim 
metodologijama. Cijeli skup znanja bi bilo moguće predstaviti 
u informacijskom sustavu. 

Takav pristup bi se idealno uklopio u završni korak zrelosti 
procesa, optimizaciju, kao neprekidno usavršavanje postojeće 
procesa. 

Naravno, u tijeku nastanka generičke metodologije bi 
trebalo provesti kvalitativnu analizu primjenjivosti 

metodologije na različite vrste projekta, kao i riješiti 

upravljanje resursima jer je moguće da bi nekoliko projekata, 
svaki upravljan svojom metodologijom, sa svojim pravilima, 
u isto vrijeme dijelili resurse i to različitim intenzitetom. 
Optimizacija dijeljenih resursa nameće se kao vrlo važan dio 
u procesu upravljanja projektima, odnosno u upravljanju 
portfeljem. Na kraju, ne treba zanemariti niti intema pravila 
organizacije koja također utječu na odabir metodologije. 

Područje upravljanja projektom doživjelo je velike 
promjene, međutim, još se i dalje intenzivno razvija. U tom 
razvoju treba voditi računa i o potrebama budućih projekata i 
postaviti proces na najviši stupanj zrelosti kako bi se 
osigurala što veća fleksibilnost. 
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